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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 



This Technical Specification (TS) has been produced by ECMA on behalf of its members and those of the European 
Telecommunications Standards Institute (ETSI). 



Brief history 



The present document is one of a series of ECMA standards defining mapping functions in exchanges of Private 
Integrated Services Networks required for the utilization of intervening network scenarios. The series uses the ISDN 
concepts as developed by ITU-T (formerly CCITT) and is also within the framework of standards for open systems 
interconnection as defined by ISO. 

The present document specifies mapping functions for the type of scenarios where two or more PINXs are 
interconnected via on-demand connections using an H.323 packet network as the IVN. 

The present document is based upon the practical experience of ECMA member companies and the results of their 
active and continuous participation in the work of ISO/IEC JTCl, ITU-T, ETSI and other international and national 
standardization bodies. It represents a pragmatic and widely based consensus. 

The second edition is fully compatible with the first edition. It specifies one part of the procedures of the optional 
semi-permanent scenario in more detail. 
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Scope 



The present document specifies functions for using an H.323 packet network in order to interconnect two Private 
Integrated services Network eXchanges (PINXs) forming part of a Private Integrated Services Network (PISN). 
Interconnection is achieved by carrying the inter-PINX signalhng protocol over the H.323 call signalling channel, 
making use of the protocol tunnelling facilities of H.323, and inter-PINX user information (e.g. voice) over logical 
channels established through H.323. Each logical channel usually represents a unidirectional media stream conveyed by 
means of the Real-time Tranport Protocol (RTP). The inter-PINX signalling protocol is assumed to be QSIG, as 
specified in ECMA-143 [2], ECMA-165 [3] and other standards. 

The present document provides for an on-demand type of interconnection, where a separate H.323 call is established at 
the start of each PISN call and cleared down at the end of that call. A semi-permanent scenario where a single H.323 
call with an indefinite lifetime carries QSIG on behalf of many PISN calls is described as an additional option. 

In the scenarios covered in the present document, the PINXs participating in a call are not necessarily aware of the 
H.323 network providing the interconnection, and the features available are those of the QSIG network. This is different 
from a scenario where true interworking between QSIG and H.323 (i.e. QSIG-H.323-QSIG) is used to connect two 
PISNs or two parts of the same PISN. In this latter case all networks participate in a call on equal terms, and features are 
limited to those available in all networks and supported by the gateways. This latter scenario is outside the scope of the 
present document. 

The present document is appUcable to PINXs that can be interconnected to form a PISN using QSIG as the inter-PINX 
signalling protocol. 



Conformance 



In order to conform to the present document, a PINX shall satisfy the requirements identified in the Implementation 
Conformance Statement (ICS) proforma in annex A. 



3 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

[1] ECMA-133: "Private Integrated Services Network (PISN) - Reference Configuration for PISN 

Exchanges (PINX)". 

[2] ECMA-143: "Private Integrated Services Network (PISN) - Circuit Mode Bearer Services - 

Inter-Exchange Signalling Procedures and Protocol (QSIG-BC)". 

[3] ECMA-165: " Private Integrated Services Network (PISN) - Generic Functional Protocol for the 

Support of Supplementary Services - Inter-Exchange Signalling Procedures and Protocol 
(QSIG-GF)". 

[4] ITU-T Recommendation H. 225.0: "Call signalling protocols and media stream packetization for 

packet-based multimedia communication systems". 

[5] ITU-T Recommendation H.245: "Control protocol for multimedia communication". 
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[6] ITU-T Recommendation H.323: "Packet-based multimedia communications systems". 

[7] ITU-T Recommendation H.323 annex M.l: "Tunnelling of signalling protocols (QSIG) in H.323". 

4 Definitions 

4.1 External definitions 

For the purposes of the present document, the following definitions apply: 
Call independent signalling connection (ECMA-I65 [3]); 
C reference point (ECMA- 1 33 [ 1 ]); 
Gatekeeper (ITU-T Recommendation H.323 [6]); 
Gateway, Trunking Gateway (ITU-T Recommendation H.323 [6]); 
Intervening network (ECMA- 1 3 3 [ 1 ]) ; 
Logical channel (ITU-T Recommendation H.323 [6]); 
Preceding PINX (ECMA-165 [3]); 
Private Integrated Services Network (ECMA-133 [1]); 
Private Integrated services Network eXchange (ECMA-133 [1]); 
Q reference point (ECMA- 1 3 3 [ 1 ] ) ; 
Subsequent PINX (ECMA-165 [3]). 

4.2 Other definitions 

4.2.1 Call 

4.2.1.1 H.323 call 

A call as defined in ITU-T Recommendation H.323 [6], i.e. a point-to-point communication between two H.323 
endpoints. Here specifically a call in the H.323 network between two gateways. 

4.2.1.2 PISNcall 

A call as defined in ECMA-143 [2] and ECMA-165 [3]. 

4.2.1.3 Call segment 

A portion of a (PISN) call between two entities taking part in that call. The smallest segment is between adjacent 
entities, e.g. between two PINXs across one Inter-PINX link. 

4.2.2 Channel 

A means of bi-directional transmission of user or signalling information between two points. 

4.2.2.1 DQ-Channel 

A channel used to convey call control information between the Q reference points of two peer PINXs. 
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4.2.2.2 UQ-Channel 

A channel used to convey user information between the Q reference points of two peer PINXs. 

4.2.3 Inter-PINX Connection (IPC) 

A connection provided by an IVN between two C reference points used to transport inter-PINX information from the 
PISN control plane and/or the PISN user plane. 

4.2.4 Inter-PINX Link (IPL) 

A link between the Q reference points of two PINXs, comprising the totality of signalling transfer and user information 
transfer means. 

4.2.5 PINX roles 

4.2.5.1 Initiating PINX 

The PINX that initiates an IPL establishment request. 

4.2.5.2 Accepting PINX 

The PINX that accepts an IPL establishment request. 



5 List of acronyms 

For the purposes of the present document, the following abbreviations apply: 

GK Gatekeeper 

ICS Implementation Conformance Statement 

IP Internet Protocol 

IPC Inter-PINX Connection 

IPL Inter-PINX Link 

IVN Intervening Network 

PINX Private Integrated services Network eXchange 

PISN Private Integrated Services Network 

QSIG SIGnalling system for the Q reference point 

RAS Registration, Admission and Status 

RRQ Register ReQuest message 

RTP/RTCP Real-time Tranport Protocol / Real Time Control Protocol 

TCP Transmission Control Protocol 

UDP User Datagram Protocol 



6 Introduction 

6.1 Reference configuration 

ECMA-133 [1] defines a reference configuration for a PINX. Logically the switching and call control functions of a 
PINX communicate over an instance of the Q reference point with a peer PINX. This communication is known as an 
Inter-PINX Link (IPL) and comprises a signalling channel, known as a Dg-channel, and one or more user information 
channels, each known as a UQ-channel; see figure 1. One or more IPLs can be established between the same pair of 
PINXs. 
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Figure 1 : IPL concept 

There are many ways of implementing an IPL. In general, the IPL uses services of another network, known as an 
Intervening Network (IVN). A PINX interfaces to the IVN at the C reference point. The IVN provides connections, 
known as Inter-PINX Connections (IPCs) between the C reference points of the peer PINXs. Mapping functions within 
each PINX map the Dg-channel and the Ug-channels at the Q reference point onto one or more IPCs at the C reference 
point. 

6.2 Specific scenarios 

The present document specifies mapping functions for use when the IVN is an H.323 packet network that is used to 
provide the following types of IPC: 

• a signalling connection for carrying signalling information; and 

• a pair of UDP streams, one stream in each direction, for carrying user information over RTP. 

NOTE: Other means of transporting user information can be used, e.g. T.38 fax without RTP, an ATM virtual 
channel, or a bi-directional TCP connection instead of UDP streams. See ITU-T Recommendation 
H.323 [6] for more details. These cases are outside the scope of the present document. 

A single IPL requires a single signalling connection, for support of the Dg-channel, and one pair of UDP streams per 
UQ-channel. 

The main inter-PINX connection scenario described in the present document is an on-demand connection scenario. This 
means that an IPL is established whenever a PISN call segment is to be set up between two PINXs and released when 
the PISN call ends. An optional semi-permanent scenario is also described, where multiple concurrent or consecutive 
PISN calls can use the same IPL. 

In both scenarios the signalling connection is established by means of an H.323 call, using the protocol tunnelling 
facilities provided by ITU-T Recommendations H. 225.0 [4] and H.323 annex M.l [7]. The H. 225.0 call signalling 
connection in conjunction with the tunnelling of the QSIG signalling is used to provide the Dg-channel. The pair of 
UDP streams used to provide an inter-PINX user connection (UQ-channel) is established as H.323 logical channel(s). 
An IPL may have multiple Ug-channels. 

Figure 2 illustrates these concepts. 
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Figure 2: H.323 as Intervening Networit (IVN) 
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IPCs in support of these scenarios can be established and released at any time under the control of either PINX. In case 
of IPC failure, the H.323 network may reject a call establishment request or release an already established call. 

A single PINX can terminate a multiplicity of IPLs leading to the same and/or different peer PINXs. Each IPL 
comprises a single H.323 call. 

6.3 Relationship with H.323 gateways 

Each PINX connected to another PINX via an H.323 network represents a trunking gateway in H.323 terms. The H.323 
gateway functionality is part of the mapping functions of the PINX. No specific implementation is implied by the 
present document. The gateway function may be fully integrated or decomposed into several components (e.g. media 
gateway controller and media gateway), as explained in ITU-T Recommendation H.323 [6]. 

The tasks of the gateway include the handling of user data or media, e.g. packetization / de-packetization, and signalling 
interworking. The latter mainly enables QSIG to be tunnelled over an H.323 call, as specified in more detail in 
subsequent clauses. 

Figure 3 shows an example of the relationship between a PISN call and the underlying H.323 call which provides the 
inter-PINX link for one segment of the PISN call. 
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Figure 3: Example of the relationship between PISN call and H.323 call 

7 Capabilities at the Q reference point 

For each instance of the Q reference point: 

• one signalling channel (Dq) for carrying the inter-PINX Layer 3 signalling protocol; and 

• zero, one or more user channels (Uq) 
are provided. 

NOTE: If the Dg-channel is used only to support QSIG call-independent signalling connections, no Ug-channels 
are required. 

For a Ug-channel the following bearer capability shall be provided: 

• transfer mode: circuit mode; 

• information transfer rate: 64 kbit/s; 

• information transfer capability: speech or 3,1 kHz audio; 

• user information layer 1 protocol: G.711 A or |i law. 

Other bearer capabilities may also be provided (e.g. 64 kbit/s unrestricted digital information, or transfer rates other 
than 64 kbit/s). 
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For a DQ-channel the following bearer capability shall be provided: 

• transfer mode: packet mode; 

• information transfer rate: implementation-dependent; 

• information transfer capability: unrestricted digital information. 

The functions to map Dg- and UQ-channels to an Inter-PINX Connection (IPC) at the C reference point are described in 
clause 9. 

8 Capabilities at the C reference point 

A PINX shall support a packet network interface suitable for multimedia communication according to 
ITU-T Recommendation H.323 [6]. The protocol stack shall conform to ITU-T Recommendations H.323 [6], 
H. 225.0 [4] and H.245 [5] and shall support protocol tunnelling according to ITU-T Recommendation H.323 
annex M.l [7]. 

NOTE: This means that the following protocols are used: 

- H. 225.0 RAS, if a gatekeeper is present, over UDP/IP; 

- H. 225.0 call control signalling, with embedded QSIG tunnel, over TCP/IP; 

- H.245 within fastStart elements and/or embedded in H. 225.0 call control or explicit over TCP/IP; 

- RTP/RTCP over UDP/IP. 

The protocol tunnelling capability of the H.323 call signalling channel serves as the IPC for the DQ-channel. A pair of 
H.323 logical channels for media transport serves as the IPC for a Ug-channel. 

For the on-demand scenario a new H.323 call is established every time a PISN call occurs and cleared when the PISN 
call finishes. 

For the optional semi-permanent scenario the same H.323 call serves multiple concurrent or consecutive PISN calls. In 
this case logical channels are dynamically opened and closed according to the number of Ug-channels required at the 
time. 

9 IVIapping functions 
9.1 General requirements 

For each IPL terminating at a PINX, the PINX shall provide mapping functions for: 

• mapping of the Dg-channel onto a packet mode IPC as provided by the H.323 call signalling channel with 
embedded QSIG tunnel; 



• 



mapping of the UQ-channel(s) onto the corresponding IPC(s) with an information transfer rate of 64 kbit/s as 
provided by H.323 logical channels (pair(s) of UDP streams). 



9.2 Mapping of the Da-channel 



The signalling carriage mechanism (see clause 6.3 of ECMA-143 [2]) is provided by the protocol tunnelling facilities of 
H.323. There is no layer 2 frame structure. The PINX shall embed a complete QSIG message in the appropriate data 
structure of the transporting H. 225.0 message without segmentation. 
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The services and primitives listed in ECMA-143 [2] clause 6.3 can be mapped to the sending and receipt of appropriate 
H. 225.0 messages. Details are left to the implementation. 



9.3 Mapping of the UQ-channel(s) 



The PINX shall map each Ug-channel to a pair of unidirectional H.323 logical channels with suitable transport 
capabilities. The mapping function is responsible for proper packetization, de-packetization, transcoding etc. of media 
data. 

9.3.1 On-demand scenario 

The PINX shall establish a single pair of unidirectional logical channels using RTP over UDP, and assign session 
identifier "1" to it, which shall also be the number of the UQ-channel mapped to this pair. 

NOTE: Other alternatives, e.g. a bi-directional logical channel or multiple UQ-channels for nx64 kbit/s, are 
outside the scope of the present document. 

9.3.2 Semi-permanent scenario 

For each UQ-channel the PINX shall establish a pair of unidirectional logical channels using RTP over UDP. The 
session identifier "n" assigned to this pair by the master side (in the range 1...255) shall be the number of the 
UQ-channel mapped to this pair. See ITU-T Recommendations H.323 [6] and H.245 [5] for more information. 

NOTE 1 : The number of established Ug-channels can be either static or dynamically adapted to the actual call load, 
assuming one channel per call. 

NOTE 2: Other alternatives, e.g. use of bi-directional logical channels or multiple Ug-channels per call in case of 
nx64 kbit/s, are outside the scope of the present document. 



10 IPC control procedures 
10.1 Protocol identification 

This clause makes reference to an object identifier identifying the QSIG protocol, here called QSIG object identifier. 
The value of this object identifier is: 

{iso (1) identified-organization (3) icd-ecma (0012) private-isdn-signalling-domain (9)}. 



10.2 Registration with gatekeeper 



If a gatekeeper exists in the H.323 domain the PINX shall register as a gateway with its gatekeeper in accordance with 
ITU-T Recommendations H.323 [6] and H.225.0 [4] before sending or receiving any calls. The PINX can detect the 
gatekeeper to register with by using one of the methods described in ITU-T Recommendations H.323 [6] and 
H.225.0 [4]. 

The gatekeeper will then: 

• assist in identifying the peer PINX from a call's destination number; and 

• provide other PINXs with the IP address of this PINX. 

The PINX shall set the terminalType.supportedXunnelledProtocols.id.tunnelledProtocolObjectlD to the QSIG 
object identifier in the Register ReQuest message (RRQ) to inform the gatekeeper that it is able to handle QSIG 
signalling. 
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1 0.3 Systems without gatekeeper 

In scenarios without a gatekeeper each PINX has to know the IP address(es) of its potential peer(s), e.g. through static 
configuration. 

1 0.4 H.323 call establishment 

10.4.1 Call admission 

If the initiating PINX has registered with a gatekeeper and has not received pre-granted admission for outgoing calls in 
the RCF message from the gatekeeper, the PINX shall send an ARQ message to the gatekeeper prior to call 
establishment. 

NOTE 1: ARQ may still be sent in the case of pre-granted admission, too. 

NOTE 2: Pre-granted admissions only make sense if a suitable call signalling transport address is known a priori, 
e.g. the signalling transport address of the GK if all calls are routed via the gatekeeper. 

The ARQ message shall contain: 

• desiredTunnelledProtocol.id.tunnelledProtocolObjectID set to the QSIG object identifier; 

• destinationlnfo with an alias address of the intended destination (i.e. an alias address sufficient to identify the 
peer PINX). The format is implementation dependent, e.g. a number in the form of 
partyNumber.privateNumber or partyNumber.el64Number. 

On receipt of an ACF message in response, the initiating PINX shall attempt to establish the H.323 call according to 
clause 10.4.2. The ACF message may contain the QSIG object identifier in field 

destinationXype.supportedTunnelledProtocols, indicating that the destination is a gateway that can act as accepting 
PINX. 

On receipt of an H. 225.0 Setup message, if the accepting PINX has registered with a gatekeeper and has not received 
pre-granted admission for incoming calls in the RCF message from the gatekeeper, the PINX shall send an ARQ 
message to the gatekeeper. On receipt of an ACF message in response, the accepting PINX shall accept the H.323 call 
request subject to conditions described in clause 10.4.3. 

If admission fails the accepting PINX shall reject the H.323 call. 

1 0.4.2 Outgoing call establishment 

The initiating PINX shall send an H. 225.0 Setup message to the call signalling address received in the ACF message or 
known a priori. The Setup message shall contain: 

• the sourcelnfo.supportedTunnelledProtocols.id.tunnelledProtocolObjectID field set to the QSIG object 
identifier; 

• optionally fastStart elements as required for the immediate provision of logical channels; 

• called party number information, e.g. copied from the ACF or the QSIG SETUP message, according to H.323 
rules (i.e. Called party number information element or element destinationAddress); 

• optionally the element tunnelledSignallingMessage with the QSIG object identifier in tunnelledProtocolID, 
the complete QSIG SETUP message in messageContent, and tunnellingRequired either present (if H.323 
interworking is not possible) or absent (if H.323 interworking is possible). 

NOTE 1 : If fastStart is not included H.245 procedures can be used later on to open the required logical channels. 

NOTE 2: If supported, the initiating PINX can use H.323 interworking as a fallback if QSIG tunnelling is not 
possible. This is outside the scope of the present document. 
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Further call establishment shall follow ITU-T Recommendations H.323 [6], H. 225.0 [4] and H.245 [5]. If successful, 
the logical channel(s) opened for the H.323 call shall be mapped to UQ-channel(s) as specified in clause 9.3, and the 
PINX shall be prepared to send and receive tunnelled QSIG messages according to clause 10.5. 

10.4.3 Incoming call establishment 

A gateway receiving an H. 225.0 SETUP that was sent according to clause 10.4.2 shall accept the H.323 call if: 

• the gateway is able to handle the call (no resource constraints, admission granted); and 

• tunnelling of QSIG is supported, i.e. the gateway can act as accepting PINX. 

Call processing shall then follow ITU-T Recommendations H.323 [6], H. 225.0 [4] and H.245 [5]. In addition an 
embedded QSIG SETUP message shall be passed to QSIG protocol control. The gateway shall also include the QSIG 
object identifier in destinationlnfo.supportedXunnelledProtocols.id.tunnelledProtocolObjectlD in all H. 225.0 
messages sent back to the originating side up to and including Connect. Logical channels shall be opened by means of 
fast connect if required by the presence of fastStart elements in the received Setup message. 

NOTE: If fastStart is not present H.245 procedures can be used later on to open the required logical channels. 

The PINX shall be prepared to send and receive tunnelled QSIG messages according to clause 10.5. 

If the gateway does not support QSIG tunnelling and an embedded QSIG SETUP message was present with the 
tunnellingRequired flag set the H.323 call shall be released according to H.323. 

1 0.5 Transfer of inter-PINX signalling information 

QSIG messages shall be passed between the two peer PINXs according to ITU-T Recommendation H.323 
annex M.l [7], embedded as complete messages in tunnelledSignallingMessage.messageContent of H. 225.0 call 
control or H. 225.0 Facility messages, together with the QSIG object identifier in tunnelledProtocolID. The sending 
PINX shall embed a single QSIG message in the proper H. 225.0 message and transmit the H. 225.0 message 
immediately. Only in the semi-permanent scenario a single H. 225.0 Facility message may convey several QSIG 
messages - belonging to different PISN calls - at the same time. 

Segmentation shall not be used. 

NOTE 1 : The present document assumes transparent transport of QSIG messages by gatekeepers in case of 
gatekeeper routed H.323 calls. 

NOTE 2: Since the H.323 tunnelling mechanism allows only a single protocol to be tunnelled per H.323 call no 
other protocol can be tunnelled besides QSIG if the present document applies. 



10.6 H.323 call clearing 



The H.323 call shall be released from either side according to H.323. Clearing of the H.323 call terminates the IPCs 
provided by that call. Therefore clearing shall only be initiated if no PISN call using these IPCs is in the active state. 

After clearing of the H.323 call, the PINXs should not unregister from their gatekeepers as long as they are ready to 
establish new calls. 
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1 1 Scenario specific procedures 
11.1 On-demand scenario 

When required by the presence of a PISN call request, the preceding PINX shall establish an H.323 call towards the 
subsequent PINX as described in clause 10.4, embedding the QSIG SETUP message in the H.323 Setup message. 
Further QSIG messages shall be exchanged according to clause 10.5. 

The Channel identification information element in the embedded QSIG SETUP message shall include the Ug-channel 
number as specified in clause 9.3.1; the call references in the H. 225.0 Setup message and in the embedded QSIG 
SETUP message are independent of each other. 

If call admission procedures apply the preceding PINX shall include the received called party number in the 
destinationlnfo field of the ARQ message. The preceding PINX shall reject the PISN call if admission fails or the 
H.323 call cannot be established for any other reason. 

The H.323 call shall remain active during the lifetime of the PISN call. At the end of the PISN call the H.323 call shall 
be cleared by either side (usually by the side sending the final QSIG call clearing message). 

If the H.323 call fails and recovery cannot be achieved the PINX detecting the failure shall clear the PISN call locally. 
H.323 recovery procedures are an implementation matter outside the scope of the present document. 

The procedures above shall also apply in the case of a connection oriented bearer independent signalling connection. 
The corresponding H.323 call shall be established as a call independent signalling connection 
(see ITU-T Recommendation H.323 annex M.l [7]). Logical channels are not required. 

A UQ-channel shall be established as required by using the logical channel procedures of 

ITU-T Recommendation H.245 [5]. Usually a Ug-channel requires the opening of two unidirectional logical channels, 
one in each direction, although the use of a single bi-directional channel is possible under certain circumstances 
(see ITU-T Recommendation H.323 [6] for details). The fast connect procedure of H.323 shall be the first choice for 
opening logical channels. H.245 tunnelling or a separate H.245 channel are only needed if fast connect is not possible or 
if more extensive H.245 signalling is required. All open logical channels shall be closed when the PISN call is released. 
If a logical channel cannot be opened or is closed unexpectedly the PINX detecting the problem shall clear the PISN 
call. 

The parameters used when opening the logical channels are outside the scope of the present document but shall be 
chosen according to the required bearer capability of the Ug-channel. 

If the PISN call is cleared as a result of QSIG restart procedures the H.323 call shall also be released. 



11.2 Semi-permanent scenario 



An H.323 call may be established between two PINXs independent of a PISN call, using the procedures of clause 10. 
This H.323 call can be used for multiple PISN calls between the two PINXs, both simultaneously and consecutively. 
The maximum number of concurrent PISN calls is an implementation issue. 

The Channel identification information element in an embedded QSIG SETUP message shall include the number of the 
Ug-channel to be used as specified in clause 9.3.2; the call references in the H. 225.0 message and in the embedded 
QSIG message are independent of each other. The call references of the QSIG messages are used to distinguish between 
different PISN calls. 

NOTE 1: The QSIG call references are unique within the context of the underlying H.323 call. Multiple H.323 calls 
over the same interface will have different callldentifler values. 

A PISN call can be established from either side by embedding the QSIG SETUP and all subsequent messages in 

H. 225.0 Facility messages. All QSIG messages will be transported in H. 225.0 Facility messages, i.e. no QSIG SETUP 

message will be embedded in the H. 225.0 Setup message. 
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All UQ-channels shall be established by means of H. 245 logical channel procedures. UQ-channels shall be added or 
dropped dynamically as needed, on a per-PISN-call basis, using H.245 tunnelling within H.225.0 messages. Other 
methods of logical channel establishment are outside the scope of the present document. 

NOTE 2: Each PINX has to open one unidirectional logical channel (the one it intends to transmit on) of the pair 
comprising a UQ-channel. 

For call establishment from the master side PINX to the slave side PINX (master and slave roles having been 
determined by the usual H.245 procedure when the IPL was established as an H.323 call), the master side PINX shall 
tunnel an H.245 OpenLogicalChannel message with session identifier "n" for its transmit logical channel in the same 
Facility message that carries the QSIG SETUP message with channel number "n". The slave side PINX shall respond 
by tunnelling two H.245 messages - OpenLogicalChannelAck for the receive logical channel and 
OpenLogicalChannel with session identifier "0" for its own transmit logical channel - in the Facility message that 
carries the first QSIG response message (e.g. CALL PROCEEDING). The master side PINX shall finalise logical 
channel establishment by returning a Facility message containing a tunnelled OpenLogicalChannelAck message with 
session identifier "n" for the receive logical channel. This case is illustrated in figure 4. 



Master 



Slave 



Facility (Setup(Ch#=n), OLC(SesslD=n)) 



Facility (CallProc(Ch#=n), OLCAck, OLC(SesslD=0)) 



Facility (OLCAck(SesslD=n)) 



Figure 4: Uq Channel mapping for a call in the direction master to slave 

For call establishment from the slave side PINX to the master side PINX, the slave side PINX shall tunnel an H.245 
OpenLogicalChannel message with session identifier "0" for its transmit logical channel in the same Facility message 
that carries the QSIG SETUP message with channel number "n". The master side PINX shall respond by tunnelling two 
H.245 messages - OpenLogicalChannelAck with session identifier "n" for the receive logical channel and 
OpenLogicalChannel also with session identifier "n" for its own transmit logical channel - in the Facility message that 
carries the first QSIG response message (e.g. CALL PROCEEDING). The slave side PINX shall finalize logical 
channel establishment by returning a Facility message containing a tunnelled OpenLogicalChannelAck message for 
the receive logical channel. This case is illustrated in figure 5. 



Master 



Slave 



Facility (Setup(Ch#=n), OLC(SesslD=0)) 



Facility (CallProc(Ch#=n), OLCAck(SesslD=n), 
OLC(SesslD=n)) 



Facility (OLCAck) 



Figure 5: Uq Channel mapping for a call in the direction slave to master 
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If the channel number "n" proposed by the slave side PINX is not acceptable to the master side PINX (e.g. in case of 
crossing SETUP messages indicating the same channel number) clause 10.3 of ECMA-143 [2] shall apply, with the 
master side PINX acting as "A" side and the slave side PINX as "B" side. The slave side PINX should always indicate 
"preferred" in the Channel identification information element, allowing the master side PINX to select a different value 
"n" in its response to the slave side PINX if necessary. 

The H.323 call can be maintained as long as desired even if no PISN calls are active. 

If the H.323 call fails and recovery cannot be achieved this terminates the IPL. Any PISN calls active at the time of 
failure shall be cleared. H.323 recovery procedures are an implementation matter outside the scope of the present 
document. 

If a logical channel required for a PISN call cannot be opened or is closed unexpectedly the PINX detecting the problem 
shall release the PISN call. 

The H.323 call shall not be cleared as a result of QSIG restart procedures, but resources that are occupied by the PISN 
call(s) affected by the restart shall be released. 
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Annex A (normative): 

Implementation Conformance Statement (ICS) Proforma 

A.1 Introduction 

A.1 .1 Purpose of an ICS proforma 

The supplier of an implementation which is claimed to conform to the present document shall complete the following 
Implementation Conformance Statement (ICS) proforma. 

A completed ICS proforma is the ICS for the implementation in question. The ICS is a statement of which capabilities 
and options have been implemented for a given specification. 

The ICS can have a number of uses, including use: 

• by the implementor, as a check list for implementations to reduce the risk of unintended non-conformance, 
e.g. through oversight; 

• by the supplier and acquirer, or potential acquirer, of the implementation, as a detailed indication of the 
capabilities of the implementation, stated relative to the common basis for understanding provided by the 
Standard's ICS proforma; 

• by the user or potential user of the implementation, as a basis for initially checking the possibility of 
interworking with another implementation - while interworking can never be guaranteed, failure to interwork 
can often be predicted from incompatible ICS; 

• by a tester, as the basis for selecting appropriate tests against which to assess the claim for conformance of the 
implementation. 



A.2 Instructions for completing the ICS proforma 
A.2.1 General structure of the ICS proforma 

The ICS proforma is a fixed format questionnaire divided into clauses each containing a group of individual items. Each 
item is identified by an item reference, the description of the item (question to be answered), and the reference(s) to the 
clause(s) that specifies (specify) the item in the main body of the present document. 

The "Conditions for Status" column contains a specification, if appropriate, of the predicate upon which a conditional 
status is based. The indication of an item reference in this column indicates a simple-predicate condition (support of this 
item is dependent on the support marked for the referenced item). 
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The "Status" column indicates whether an item is appUcable and if so whether support is mandatory or optional. The 
following terms are used: 

I Informational, irrelevant or out-of-scope - this capability is outside the normative scope of the standard 

to which this ICS proforma applies and is not subject to conformance testing in this context; 

M Mandatory (the capability is required for conformance to the standard); 

N/A Not Applicable - in the given context, it is impossible to use the capability; no answer in the support 

column is required, 

O Optional (the capability is not required for conformance to the standard, but if the capability is 

implemented it is required to conform to the specification in the present document); 

0.<n> qualified Optional - in this case, <n> is an integer that identifies a unique group of related optional 

items; if no additional qualification is indicated, the support of at least one of the optional items is 
required for conformance to the present document; otherwise, the qualification and logic of the 
selection among the optional items is defined below the table explicitly; 

X excluded or prohibited - there is a requirement not to use this capability in a given context. 

Answers to the questionnaire items are to be provided in the "Support" column, by simply marking an answer to 
indicate a restricted choice (Yes, No or N/A). In specific cases, the indication of explicit values may be requested. 
Where a support column box is left blank, no answer is required. 

If a "prerequisite line" (see clause A.2.4) is used after a clause heading or table title, and its predicate is false, no answer 
is required for the whole clause or table, respectively. 

A.2.2 Additional information 

Items of additional information allow a supplier to provide further information intended to assist the interpretation of 
the ICS. It is not intended or expected that a large quantity will be supplied, and an ICS can be considered complete 
without any such information. Examples might be an outline of the ways in which a (single) implementation can be set 
up to operate in a variety of environments and configurations. 

References to items of additional information may be entered next to any answer in the questionnaire, and may be 
included in items of exception information. 



A.2.3 Exception information 



It may occasionally happen that a supplier will wish to answer an item with mandatory or prohibited status (after any 
conditions have been applied) in a way that conflicts with the indicated requirement. No pre-printed answer will be 
found in the Support column for this. Instead, the supplier is required to write into the support column an x.<i> 
reference to an item of exception information, and to provide the appropriate rationale in the exception item itself. 

An implementation for which an exception item is required in this way does not conform to the present document. A 
possible reason for the situation described above is that a defect in to the present document has been reported, a 
correction for which is expected to change the requirement not met by the implementation. 
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A.2.4 Further indications of the ICS proforma tables 

In addition to the columns of a table, the following information may be indicated: 

"Prerequisite line" 

A prerequisite line after a clause heading or table title indicates that the whole clause or the whole table is not 
required to be completed if the predicate is false. 

"QuaHfication" 

At the end of a table, a detailed qualification for a group of optional items may be indicated, as specified in the 
description of the status "qualified optional" in clause in clause A.2.1. 

"Comments" 

This box at the end of a table allows a supplier to enter any comments to that table. Comments may also be provided 
separately (without using this box). 



A.3 Identification of the implementation 



A.3.1 Implementation Identification 



Supplier (note 1) 




Contact point for queries about the ICS (note 1 ) 




Implementation Name(s) and Version{s) (note 1 , 
note 2) 




Other information necessary for full identification - 
e.g. name(s) and version(s) for machines and/or 
operating systems; System name(s) 




NOTE 1 : Only the first three items are required for all implementations; other information may be completed as 

appropriate in meeting the requirement for full identification. 
NOTE 2: The terms Name and Version should be interpreted appropriately to correspond with a suppliers 

terminology (e.g. Type, Series, Model). 



A.3. 2 Specification for which this ICS applies 



Title 


Private Integrated Services Network (PISN) -Mapping 
Functions for the tunnelling of QSIG through H.323 
networks 


Version 


1.0 


Corrigenda Implemented (if applicable) 




Addenda Implemented (if applicable) 




Amendments Implemented (if applicable) 




Have any exception items been required ? 


No[ ] Yes[ ] 

(The answer Yes means that the implementation does 

not conform to the present document) (see note) 


Date of Statement 




NOTE: In this case, an explanation shall be given of the nature of non-conformance either below or on a 

separate sheet of paper. 
Nature of non-conformance (if applicable): 
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A.4 


Genera requirements 






Item 


Question: 
Does the implementation ... 


Condition for 
status 


Status 


Reference 


Support 


A1 


act as initiating PINX 




0.1 




[]Yes 
[]No 


A2 


act as accepting PINX 




0.1 




[]Yes 
[]No 


A3 


support tlie on-demand scenario 




M 




[]Yes 


A4 


support ttie semi-permanent scenario 









[]Yes 
[INo 


A4.1 


IVIaximum number of concurrent PISN calls 


A4 


1 




Value: 


A5 


support a packet network interface with 
H.323 protocol stack with QSIG tunnelling 




M 


8 


[]Yes 


A6 


support general mapping requirements 




M 


9.1 


[]Yes 


A7 


support mapping of the DQ-channel 




M 


9.2 


[]Yes 


A8 


support mapping of the UQ-channel in the 
on-demand scenario 




M 


9.3.1 


[]Yes 


A9 


support mapping of Ug-channels in the 
semi-permanent scenario 


A4 


M 


9.3.2 


[]Yes 



Comments 



A.5 Procedures 



Item 


Question: 
Does the implementation ... 


Condition for 
status 


Status 


Reference 


Support 


B1 


support IPC control functions - protocol 
identification 




M 


10.1 


[]Yes 


B2 


support IPC control functions with 
registration with gatekeeper 




0.1 


10.2 


[]Yes 
[INo 


B3 


support IPC control functions without 
gatekeeper 




0.1 


10.3 


[]Yes 
[]No 


84 


support IPL establishment with GK - call 
admission 


B2 


M 


10.4.1 


[]Yes 


B5 


support IPL establishment - outgoing call 


A1 


M 


10.4.2 


[lYes 


B6 


support IPL establishment - incoming call 


A2 


M 


10.4.3 


[lYes 


87 


support fast connect for UQ-channel 
establishment 




0.2 


10.4.2 
10.4.3 


[]Yes 
[]No 


B8 


support separate H.245 procedures for UQ- 
channel establishment 




0.2 


10.4.2 
10.4.3 


[]Yes 
[]No 


B9 


support transfer of inter-PINX signalling 




M 


10.5 


[lYes 


BIO 


support clearing of H.323.call 




M 


10.6 


flYes 


B11 


support on-demand scenario specific 
procedures 




M 


11.1 


[]Yes 


B12 


support semi-permanent scenario specific 
procedures 


A4 


M 


11.2 


[]Yes 


Comments 
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A.6 Coding 



Item 


Question: 
Does the implementation ... 


Condition for 
status 


Status 


Reference 


Support 


C1 


include QSIG object identifier in RRQ 


B2 


M 


10.2 


flYes 


C2 


include QSIG object identifier in ARQ 


B4 


M 


10.4.1 


[jYes 


C3 


include QSIG-specific H.225.0-UUIE 
element values in Setup or Facility and 
receive them in all messages 


B5 


M 


10.4.2, 10.5, 
11.1 


[jYes 


C4 


receive QSIG-specific H.225.0-UUIE 
element values in Setup or Facility and 
include them in backwards messages or 
Facility 


B6 


M 


10.4.3, 10.5, 
11.1 


[jYes 


C5 


include and receive all QSIG messages in 
H. 225.0 Facility messages 


B12 


M 


11.2 


[jYes 


Comments 
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Annex B (informative): 
Examples of message sequences 

List of abbreviations used in the message sequences: 



Ch 


Channel number 


cpn 


called party number 


CR 


Call Reference 


DL 


Data Link 


MP 


Mapping Function / gateway 


PC 


Protocol Control 



The following convention is used for message names: QSIG and H.225.0/RAS message names are all upper case, 
H. 225.0 call control message names are lower case with the first letter in upper case. 



B.1 Successful call setup 
B.1.1 Enbloc sending 

Figure B.l shows an example message sequence for a successful call between two PINXs where the called party 
number in the original QSIG SETUP message is complete. RAS procedures are optional. The call signalling follows the 
direct call model, i.e. the signalling is not routed via a gatekeeper. 



PC 



MP 



GK 



DL-DATA-REQ 



(SETUP (CR1,ch1)) 



DL-DATA-IND 



(CALLPR0C(CR1, chl)) 



DL-DATA-IND 



(ALERTING (CR1)) 
DL-DATA-IND 



(CONNECT (CR1)) 



ARQ 



MP 



PC 



ACF 
Setup (CR2, fastStart, SETUP (CR1, ch1)) 



Call Proceeding (CR2) 




Facility (CR2, CALL PROC (CR1 , ch1 )) 



^ Alerting (CR2, fastStart, ALERTING (CR1 )) 



Connect (CR2, fastStart, CONNECT (CR1)) 



Media established 



DL-DATA-IND 



(SETUP (CR1,ch1)) 



DL-DATA-REO 



(CALL PROC (CRl, chl)) 



DL-DATA-REO 



(ALERTING (CR1)) 
, DL-DATA-REO 



(CONNECT (CR1)) 



Figure B.1 : Enbloc setup, successful call, direct call model, with fast connect 
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B.1.2 Overlap sending 



Figure B.2 shows an example message sequence for a successful call between two PINXs where the called party 
number in the original QSIG SETUP message is not complete. RAS procedures are optional. The call signalling follows 
the gatekeeper routed model. 

Note that due to the large number of options in H.323 there are many more scenarios possible. 



PC 



DL-DATA-REQ 



(SETUP (CR1,ch1)) 




DL-DATA-IND 



(SETUP ACK(CRl,chl)) 
DL-DATA-REQ 



(INF0(CR1,cpn)) 



DL-DATA-IND 



(CALL PROC (CRD) 



DL-DATA-IND 



(ALERTING (CR1)) 
DL-DATA-IND 



(CONNECT (CR1)) 



(Setup (CR2, 



fastStal, SETUP (CR1,clT 



Call Proc (CR2) 



Facility (CR2, 



Facility (CR2, 



Facility (CR2, 



Alerting (CR2, 



Connect (CR2, 



Med 



GK 



MP 



PC 



(Setup (CR3, 



Call Proc (CR3) 




Facility (CR3, 



ETUPACK(CR1,ctti1)) 
Facility (CR3, 



.INF0(CR1,cpn)) 



Facility (CR3, 



CALL PROC (CR1)) 



Alerting (CR3, 



fastStart, ALERTING (Cpi)) 
Connect (CR3, 



. fastptart, CONNECT 
dia established 



(C=i1 



(Setup (CR4, 



.all Proc (CR4) 



Facility (CR4, 



Facility (CR4, 



Facility (CR4, 



Alerting (CR4, 



Connect (CR4, 
)) 



DL-DATA-IND 



(SETUP (CR1, Chi)) 



DL-DATA-REO 



(SETUP ACK(CRl,chl)) 



DL-DATA-IND 



(INF0(CR1,cpn)) 



DL-DATA-REQ 



(CALL PROC (CRD) 



^L-DATA-REQ 



(ALERTING (CR1)) 
j pL-DATA-REQ 



(CONNECT (CR1)) 



Figure B.2: Overlap sending, successful call, GK routed call model, with fast connect 
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B.2 Normal call clearing 



Figure B.3 shows an example of call clearing from the active state. Clearing is initiated from the called side. 
For clearing from the calling side the flow is mirrored. 



PC 



MP 



MP 



PC 



^^ 




Active call 




fc^ 


DL-DATA-IND 


Facility (CR2, DISCONNECT (CR1)) 


^ DL-DATA-REO 


(DISCONNECT (CRD) 
DL-DATA-IND 


Facility (CR2, RELEASE (CR1 )) ^ 


(DISCONNECT (CRD) 
DL-DATA-REQ 


(RELEASE (CRD) 
DL-DATA-IND 


Rel Com (CR2, REL COM (CR1 )) 


(RELEASE (CRD) ' 
^ DL-DATA-REO 


(REL COM (CRD) 




(RELCOM (CRD) 


DCF,,,.--^ 


iK Gl 


< DR9..,.--' 



Figure B.3: Normal call clearing by called side 
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